Patient hydration system with abnormal reading detection

ABSTRACT

A patient hydration system including an infusion device for administering hydration fluid to a patient, and a hydration fluid measurement device responsive to a source of hydration fluid, a patient urine output measurement device. A controller is responsive to the hydration fluid measurement device and the patient urine output measurement device. The controller operates the infusion device, in response to the patient urine output measurement device and the hydration fluid measurement device, to hydrate the patient based on the patient&#39;s urine output. The controller also monitors the operation history of the infusion device thereby providing redundancy in the measurement of the amount of hydration fluid administered to the patient.

RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 11/408,851, filed Apr. 21, 2006 which is acontinuation-in-part application of U.S. patent application Ser. No.10/936,945, filed Sep. 9, 2004. All of the above applications are hereinincorporated by reference in their entirety.

FIELD OF THE INVENTION

This invention relates to a patient hydration system and method whereinthe rate of hydration fluid delivered to the patient is automaticallyadjusted based on the urine output of the patient to maintain, asnecessary, a zero, positive, or negative net fluid balance in thepatient.

BACKGROUND OF THE INVENTION

The “cath lab” in a hospital is where a patient is injected with aradiocontrast media, imaged, diagnosed, and often operated on.Typically, a cardiologist refers the patient to the cath lab and thepatient is instructed not to eat or drink the night before. In the caseof a patient suffering a heart attack, the patient may be transferreddirectly to the cath lab.

Often, the patient is dehydrated when the patient arrives at the cathlab. The patient is prepped and the radiocontrast media injected. If,after imaging, a possible problem is detected, intervention occurs inthe form of angioplasty, the placement of a stent, heart valve repairsurgery, and the like. During these procedures, additional radiocontrastmedia may be injected into the patient and the patient imaged so thecardiac surgeon can view the progress of the operation.

Unfortunately, the radiocontrast media is toxic to the patientespecially a patient who is dehydrated at the time the radiocontrastmedia is injected. A patient who already suffers from various medialproblem such as diabetes or kidney problems is even more prone to medialproblems due to the injection of the radiocontrast media.

It has been observed that dehydration increases the risk ofradiocontrast nephropathy (RCN) when radiocontrast agents are injectedinto a patient during coronary and peripheral vascular catheterizationprocedures. RCN is the third most common cause of hospital-acquiredrenal failure. It occurs in over 5% of patients with any baseline renalinsufficiency and in 50% of patients with preexisting chronic renalinsufficiency and diabetes. Radiocontrast media has a variety ofphysiologic effects believed to contribute to the development of RCN.One of the main contributors is renal medullary ischemia, which resultsfrom a severe, radiocontrast-induced reduction in renal/intrarenal bloodflow and oxygen delivery. The medullary ischemia induces ischemia and/ordeath of the metabolically active areas of the medulla responsible forurine formation, called the renal tubules. Medullary ischemia isattributed to the increase of oxygen demand by the kidney struggling toremove the radiocontrast media from blood plasma and excrete it from thebody at the same time as the normal process of controlling theconcentration of urine. Oxygen consumption in the medulla of the kidneyis directly related to the work of concentrating urine. Since thepresence of radiocontrast media in the urine makes it much moredifficult for the kidney to concentrate urine, the work of the medullaoutstrips the available oxygen supply and leads to medullary ischemia.

Although the exact mechanisms of RCN remain unknown, it has beenconsistently observed that patients with high urine output are lessvulnerable to contrast injury. It is also clear that dehydrationincreases the risk of RCN, likely because urine (and contrast mediainside the kidney) is excessively concentrated. As a result, patientspredisposed to RCN are hydrated via intravenous infusion of normalsaline before, during and after the angiographic procedure. Hydration iscommonly performed at a conservative rate, especially in patients withexisting heart and kidney dysfunction, since over-hydration can resultin pulmonary edema (fluid in the lungs), shortness of breath, the needfor intubation, and even death. Thus, the patients at highest risk forRCN are those least likely to receive the only proven therapy forpreventing RCN (I.V. hydration) due to the unpredictability of sideeffects from I.V. hydration.

A major limitation to the more widespread use of the already knowntherapeutic, or optimal, levels of I.V. hydration is the currentinability to balance the amount of fluid going into the patient to theamount of fluid being removed or excreted from the patient. It ispossible to have a nurse measure a patient's urine output frequently butthis method is impractical as nurses are often responsible for the careof many patients. In addition, the only accurate method of measuringurine output is to place a catheter into the patient's urinary bladder.Without a catheter, the patient must excrete the urine that may havebeen stored in the bladder for several hours. During this time, theamount of I.V. hydration can be significantly less than the amount ofurine produced by the kidneys and stored in the bladder, leading todehydration. Since patients do not normally have such a catheter duringprocedures using radiocontrast media, a valid measurement of urineoutput is not possible.

There seems to be indisputable scientific evidence that RCN in patientswith even mild baseline renal insufficiency can lead to long termcomplications and even increased risk of mortality. This scientificknowledge has not yet been extended to daily clinical practice asroutine monitoring of renal function post-catheterization is notperformed and limits the identification of the known short-term clinicalcomplications.

At the same time, there is a great deal of awareness in clinicalpractice that patients with serious renal insufficiency (serumcreatinine (Cr)≧2.0) often suffer serious and immediate damage fromcontrast. Many cardiologists go considerable length to protect thesepatients including slow, overnight hydration (an extra admission day),administration of marginally effective but expensive drugs, or even notperforming procedures at all.

There are approximately 1 million inpatient and 2 million outpatientangiography and angioplasty procedures performed in the U.S. per year(based on 2001 data). Based on the largest and most representativepublished studies of RCN available to us (such as Mayo Clinic PCIregistry of 7,586 patients) we believe that 4% of patients have seriousrenal insufficiency (Cr≧2.0). This results in the initial marketpotential of 40 to 120 thousand cases per year from interventionalcardiology alone. There is also a significant potential contributionfrom peripheral vascular procedures, CT scans and biventricularpacemaker leads placement. As the awareness of the RCN increases, themarket can be expected to increase to 10% or more of all cases involvingcontrast.

According to the prior art, hydration therapy is given intravenously(I.V.) when someone is losing necessary fluids at a rate faster thanthey are retaining fluids. By giving the hydration therapy with an I.V.,the patient receives the necessary fluids much faster than by drinkingthem. Also, dehydration can be heightened by hyperemesis (vomiting),therefore the I.V. method eliminates the need to take fluids orally. Ananesthetized or sedated patient may not be able to drink. Hydration isused in clinical environments such as surgery, ICU, cathlab, oncologycenter and many others. At this time, hydration therapy is performedusing inflatable pressure bags and/or I.V. pumps. A number of I.V. pumpson the market are designed for rapid infusion of fluids (as opposed toslow I.V. drug delivery) for perioperative hydration during surgery, ICUuse and even emergency use for fluid resuscitation.

An infusion pump is a device used in a health care facility to pumpfluids into a patient in a controlled manner. The device may use apiston pump, a roller pump, or a peristaltic pump and may be poweredelectrically or mechanically. The device may also operate using aconstant force to propel the fluid through a narrow tube, whichdetermines the flow rate. The device may include means to detect a faultcondition, such as air in, or blockage of, the infusion line and toactivate an alarm.

An example of a device for rapid infusion of fluids is the InfusionDynamics (Plymouth Meeting, Pa.) Power Infuser. The Power Infuser usestwo alternating syringes as a pumping engine. Since it is only intendedto deliver fluids (not medication), the Power Infuser has accuracy of15%. It provides a convenient way to deliver colloid as well ascrystalloid for hydration during the perioperative period among otherpossible clinical settings. The Power Infuser provides anesthesiologistswith the ability to infuse at rates similar to that seen with pressurebags, but with more exact volume control. The maximum infusion rate is 6L/hr. It has the flexibility of infusing fluid at 0.2, 1, 2, 4 and 6L/hr. A bolus setting of 250 mL will deliver that volume in 2.5 min. Ina large blood loss surgical case, the use of Power Infuser enables largevolumes of colloid to be delivered to restore hemodynamics.

It is also known in the art that loop diuretics such as furosemide(frusemide) reduce sodium reabsorption and consequentially reduce oxygenconsumption of the kidney. They also reduce concentration of contrastagents in the urine-collecting cavities of the kidney. They inducediuresis (e.g., patient produces large quantities of very dilute urine)and help remove contrast out of the kidney faster. Theoretically, theyshould be the first line of defense against RCN. In fact, they were usedto prevent RCN based on this assumption until clinical evidencesuggested that they were actually deleterious. More recently, doubtshave been raised regarding the validity of those negative clinicalstudies.

In two clinical studies by Solomon R., Werner C, Mann D. et al. “Effectsof saline, mannitol, and furosemide to prevent acute decreases in renalfunction induced by radiocontrast agents”, N Engl J Med, 1994;331:1416-1420 and by Weinstein J. M., Heyman S., Brezis M. “Potentialdeleterious effect of furosemide in radiocontrast nephropathy”, Nephron1992; 62:413-415, as compared with hydration protocol, hydrationsupplemented with furosemide adversely affected kidney function inhigh-risk patients given contrast. Weinstein et al. found thatfurosemide-treated subjects lost 0.7 kg on average, whereas a 1.3-kgweight gain was noted in patients randomized to hydration alone,suggesting that in furosemide-treated subjects the hydration protocolhas been insufficient and patients were dehydrated by excessivediuresis.

The clinical problem is simple to understand: diuresis is widelyvariable and unpredictable but the fluid replacement (hydration) at aconstant infusion rate is prescribed in advance. To avoid the risk ofpulmonary edema, fluid is typically given conservatively at 1 ml/hr perkg of body weight. The actual effect of diuretic is typically not knownfor 4 hours (until the sufficient amount of urine is collected andmeasured) and it is too late and too difficult to correct any imbalance.Meanwhile, patients could be losing fluid at 500 ml/hour while receivingthe replacement at only 70 ml/hour. The effects of forced diuresiswithout balancing are illustrated in the research paper by Wakelkamp et.al. “The Influence of Drug input rate on the development of tolerance tofurosemide” Br J Clin. Pharmacol. 1998; 46: 479-487. In that study,diuresis and natriuresis curves were generated by infusing 10 mg of I.V.furosemide over 10 min to human volunteers. From that paper it can beseen that a patient can lose 1,300 ml of urine within 8 hours followingthe administration of this potent diuretic. Standard unbalanced I.V.hydration at 75 ml/h will only replace 600 ml in 8 hours. As a resultthe patient can lose “net” 700 ml of body fluid and become dehydrated.If such patient is vulnerable to renal insult, they can suffer kidneydamage.

To illustrate the concept further, the effects of diuretic therapy onRCN were recently again investigated in the PRINCE study by Stevens etal. in “A Prospective Randomized Trial of Prevention Measures inPatients at High Risk for Contrast Nephropathy, Results of the PRINCE.Study” JACC Vol. 33, No. 2, 1999 February 1999:403-11. This studydemonstrated that the induction of a forced diuresis while attempting tohold the intravascular volume in a constant state with replacement ofurinary losses provided a modest protective benefit againstcontrast-induced renal injury, and importantly, independent of baselinerenal function. This is particularly true if mean urine flow rates wereabove 150 ml/h. Forced diuresis was induced with intravenouscrystalloid, furosemide, and mannitol beginning at the start ofangiography.

The PRINCE study showed that, in contrast to the Weinstein study, forceddiuresis could be beneficial to RCN patients if the intravascular volumewas held in a constant state (no dehydration). Unfortunately, there arecurrently no practical ways of achieving this in a clinical settingsince in response to the diuretic infusion the patient's urine outputchanges rapidly and unpredictably. In the absence of special equipment,it requires a nurse to calculate urine output every 15-30 minutes andre-adjust the I.V. infusion rate accordingly. While this can be achievedin experimental setting, this method is not possible in current clinicalpractice where nursing time is very limited and one nurse is oftenresponsible for monitoring the care of up to ten patients. In addition,frequent adjustments and measurements of this kind often result in ahuman error.

Forced hydration and forced diuresis are known art that has beenpracticed for a long time using a variety of drugs and equipment. Thereis a clear clinical need for new methods and devices that will make thistherapy accurate, simple to use and safe.

SUMMARY OF THE INVENTION

It is therefore an object of this invention to provide a patienthydration system and method.

It is a further object of this invention to provide such a system andmethod which prevents kidney damage in a patient.

It is a further object of this invention to provide such a system andmethod which protects the patient undergoing a medical procedureinvolving a radiocontrast agent from kidney damage.

It is a further object of this invention to provide such a system andmethod which incorporates a balancing feature intended to preventdehydration, overhydration, and to maintain a proper intravascularvolume.

It is a further object of this invention to provide a balanced diuresismethod which automatically balances fluid loss in the urine.

It is a further object of this invention to provide such a system andmethod which is accurate, easy to implement, and simple to operate.

It is a further object of this invention to provide such a system andmethod which is particularly useful in the clinical setting of forceddiuresis with drugs known as I.V. loop diuretics.

It is a further object of this invention to provide such a system andmethod in which the amount of hydration fluid injected into the patientis confirmed by a redundant control loop.

The subject invention results from the realization that radiocontrastnephropathy in particular and patient dehydration in general can beprevented by automatically measuring the urine output of the patient andadjusting the rate of delivery of a hydration fluid to the patient toachieve, as necessary, a zero, positive, or negative net fluid balancein the patient. Redundancy and safety is provided by controlling theinfusion rate based both on the operation history of the infusion pumpand a separate measurement of the fluid pumped out of the source ofhydration fluid.

The subject invention, however, in other embodiments, need not achieveall these objectives and the claims hereof should not be limited tostructures or methods capable of achieving these objectives.

A patient hydration system in accordance with this invention features aninfusion device for administering hydration fluid to a patient. Ahydration fluid measurement device is responsive to a source ofhydration fluid. There is also a patient urine output measurementdevice. A controller is responsive to the hydration fluid measurementdevice and the patient urine output measurement device. The controllercontrols the operation of the infusion device in response to the patienturine output measurement device and the hydration fluid measurementdevice, to hydrate the patient based on the patient's urine output. Thecontroller also monitors the operation history of the infusion devicethereby providing redundancy in the measurement of the amount ofhydration fluid administered to the patient.

In one example, the controller is configured to output an alarm signalif the operation history of the infusion device yields a hydration fluidadministration quantity different from the measurement of the hydrationfluid by a first predetermined amount. Also, controller can beconfigured to adjust the operation of the infusion device if theoperation history of the infusion device yields a hydration fluidadministration quantity different from the measurement of the hydrationfluid by second predetermined amount. Typically, the controller isfurther configured to operate the infusion device at a predeterminedmaximum infusion rate irrespective of the patient's urine output and tooperate the infusion device at a predetermined minimum infusion rateirrespective of the patient's urine output.

In one example, the infusion device is a pump, the hydration fluidmeasurement device includes a weighing mechanism such as a strain gaugeresponsive to the source of hydration fluid. The patient urine outputmeasurement device may include a weighing mechanism such as a straingauge responsive to a reservoir of urine output by the patient.

A method of hydrating a patient in accordance with this inventionincludes administering hydration fluid to the patient, measuring thepatient's urine output, and controlling the amount of hydration fluidadministered to the patient based on the patient's urine output andredundantly monitoring the amount of hydration fluid administered to thepatient. Typically, the hydration fluid administered to the patient isfrom a source of hydration fluid and by an infusion device. Theoperation history of the infusion device is monitored and the source ofhydration fluid is also monitored to provide redundancy.

An alarm signal can be generated if the operation history of theinfusion device yields a hydration fluid administration quantitydifferent from the monitored source of hydration fluid by a firstpredetermined amount. Also, the operation of the infusion device can beadjusted if the operation history of the infusion device yields ahydration fluid administration quantity different from the monitoredsource of hydration fluid by second predetermined amount.

In one example, monitoring the source of hydration fluid includesweighing the source of hydration fluid and measuring the patient's urineoutput includes weighing the patient's urine output.

One fluid management system for a patient injected with a contrast agentin accordance with this invention features a console for mounting on anIV pole, a first attachment mechanism extending from the console forhanging a urine collection chamber, a first weighing device associatedwith the console and responsive to the first attachment, a secondattachment extending from the console for hanging a source of hydrationfluid, and a second weighing device associated with the console andresponsive to the second attachment for weighing the source of hydrationfluid. An infusion pump is integrated with the console and configured topump hydration fluid from the source of hydration fluid into thepatient. A controller is located in the console and is responsive to thefirst and second weighing devices. The controller controls the infusionpump to hydrate the patient based on the patient's urine output toprevent radiocontrast nephropathy. The controller monitors the amount ofhydration fluid administered to the patient based on the weight of thesource of hydration fluid and also monitors the operation of theinfusion pump.

One example of a fluid management method for a patient injected with acontrast agent features weighing the patient's urine output, weighing asource of hydration fluid, infusing hydration fluid from the source ofhydration fluid into the patient via an infusion pump, controlling theinfusion rate to hydrate the patient based on the patient's urine outputto prevent radiocontrast nephropathy, monitoring the amount of hydrationfluid administered to the patient based on the weight of the source ofhydration fluid, and monitoring operation of the infusion pump.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Other objects, features and advantages will occur to those skilled inthe art from the following description of a preferred embodiment and theaccompanying drawings, in which:

FIG. 1 is a schematic view of an example of a patient hydration systemin accordance with the subject invention;

FIG. 2 is a schematic view of one embodiment of a patient hydrationsystem in accordance with the subject invention wherein the weight ofthe urine output by a patient is measured and used as an input tocontrol the infusion rate of an infusion pump;

FIG. 3 is a schematic view of another embodiment of a patient hydrationsystem in accordance with the subject invention wherein the controllerand weighing mechanism are integrated in a single control subsystemunit;

FIG. 4 is a flow chart depicting one example of the software associatedwith the controller of this invention and the method of adjusting theinfusion rate based on the amount of urine output by the patient;

FIG. 5 is a schematic view showing another embodiment of the subjectinvention wherein a flow meter is used to determine the amount of urineoutput by the patient;

FIG. 6 is a schematic block diagram depicting one example of how thecontroller of the subject invention provides redundancy in themeasurement of the amount of hydration fluid administered to a patientby monitoring the operation of the hydration pump and also by monitoringthe weight of the source of hydration fluid;

FIG. 7 is a block diagram showing the primary steps associated with theprogramming of the controller shown in FIG. 6;

FIGS. 8A-8D are graphs showing signals indicative of an abnormal urineoutput weight measurement;

FIGS. 9A-9B are graphs showing signals indicative of an abnormalhydration fluid bag weight measurement;

FIG. 10 is a flow chart showing the primary steps associated with theprogramming of the controller shown in FIG. 6;

FIGS. 11-12 are simplified graphs depicting how the hydration fluidadministration rate is increased after a disruption in accordance withthe subject invention;

FIG. 13 is a schematic front view of an example of a user interface inaccordance with the subject invention;

FIG. 14 is a block diagram of an example of a main printed circuit boardfor an embodiment of a hydration system in accordance with thisinvention;

FIG. 15 is a timing diagram for the microprocessor and ComplexProgrammable Logic Device (CPLD) shown in FIG. 14;

FIG. 16 is a schematic front view of a prototype balanced hydration unitin accordance with the subject invention; and

FIG. 17 is a schematic front view of a portion of the user interface forthe unit shown in FIG. 16.

DETAILED DESCRIPTION OF THE INVENTION

Aside from the preferred embodiment or embodiments disclosed below, thisinvention is capable of other embodiments and of being practiced orbeing carried out in various ways. Thus, it is to be understood that theinvention is not limited in its application to the details ofconstruction and the arrangements of components set forth in thefollowing description or illustrated in the drawings. If only oneembodiment is described herein, the claims hereof are not to be limitedto that embodiment. Moreover, the claims hereof are not to be readrestrictively unless there is clear and convincing evidence manifestinga certain exclusion, restriction, or disclaimer.

Patient hydration system 10, FIG. 1 according to this invention includesurine collection system 12 connected to patient P. Infusion system 20typically includes an infusion device such as infusion pump 22 (e.g., aperistaltic pump) connected to source 24 of infusion fluid 26 (e.g.,saline) by tubing 28. I.V. needle 30 is inserted in a vein of patient Pand is connected to infusion pump 22 via tubing 32.

A control system or hydration balance means 34 detects the amount ofurine output by the patient and automatically adjusts the infusion rateof infusion pump 22 to achieve, as necessary, a zero, positive, ornegative net fluid balance in the patient. Typically, urine collectionsystem 12 includes catheter 14 (e.g., a Foley catheter) placed in thebladder B of patient P. Tubing 16 connects catheter 14 to meter 36.Controller 38, typically programmable, is responsive to the output ofmeter 36 and is configured to adjust the infusion rate of infusion pump22.

In one example, meter 36, FIG. 1 is a weight measurement device such asscale 50, FIG. 2. Here, urine collection chamber 52 on scale 50 isconnected to catheter 14 via tubing 16. Scale 50 outputs a signalcorresponding to the weight of urine or the combined weight of urine andhydration fluid (in this case to maintain net-zero hydration, the scalereading should be maintained constant) or the difference between theweight of urine and the weight of hydration fluid in collection chamber52 to controller 38. The patient hydration system of this invention mayfurther include diuretic administration system 60 including a source 62of a diuretic such as furosemide administered via I.V. 64 inserted inpatient P and connected to source 62 via tubing 66. In alternativeembodiment, tubing 66 can be connected to the patient P via hydrationI.V. 30 using standard clinical techniques. Also, if desired, a urinepump such as, for example, peristaltic pump 70 can be used to urge urinefrom bladder B to collection chamber 52 and to automatically flushcatheter 14 if it is occluded. The advantage of urine collection pump 70is that collection chamber or bag 52 can be at any height relative tothe patient P. As shown, chamber 24 containing the hydration fluid 26can also be placed on scale 50 in an embodiment where differentialweighing is used. The controller (38) electronics and software arecapable of integrating urine output (for example every 15 or 30 minutes)and changing the infusion rate setting of the infusion pump 22 followingan algorithm executed by the controller.

Electronic controller 22 may also incorporate a more advanced featureallowing the physician to set a desired (for example positive) hydrationnet goal. For example, the physician may set the controller to achievepositive net gain of 400 ml in 4 hours. Controller 38 calculates thetrajectory and adjust the infusion pump flow rate setting to exceed theurine output accordingly. For example, to achieve a positive net gain of400 ml over 4 hour, controller 38 may infuse additional 25 ml ofhydration fluid every 15 minutes in addition to the volume of urine madeby the patient in each 15 minute interval.

In the embodiment of FIG. 3, the programmable controller and theweighing mechanisms are integrated in controller unit 34″. The patient(See FIG. 1) is placed on the hospital bed or operating table 80. Thehydration I.V. 30 and the urinary collection (Foley) catheter 14 areinserted using standard methods. The controller electronics and theinfusion pump 22′ are integrated in the single enclosure of the controlsubsystem 34″ console 82. Console 82 is mounted on I.V. pole 84.

Control subsystem 34″ may also include electronic air detector 86 thatprevents infusion of air into the patient. The air detector 86 is ofultrasonic type and can detect air in amounts exceeding approximately 50micro liters traveling inside the infusion tubing 32. In one example,air detector 86 employs technology based on the difference of the speedof sound in liquid and in gaseous media. If an air bubble is detected,the pump 22′ is stopped almost instantaneously.

Console 82 may include one electronic strain gage and other weighingmeans to periodically detect the weight of the collected urine inchamber 52 and, another electronic strain gauge to detect the weight ofthe remaining hydration fluid in chamber 26. In the proposed embodiment,bag 52 with collected urine 53 and the bag 24 with hydration fluid 26are hanging off the attachments (e.g., hooks) 90 and 92 connected to thetrain gauges. Cable 91 interconnects hook 90 with urine collection bag52 to keep urine collection bag 52 below the elevation of the patient.The bags with fluids are suspended from the hooks and a system of leverstranslate force to weight. The strain gauges convert force into anelectronic signal that can be read by controller 34″. Suitableelectronic devices for accurately measuring weight of a suspended bagwith urine are available from Strain Measurement Devices, 130 ResearchParkway, Meriden, Conn., 06450. These devices include electronics andmechanical components necessary to accurately measure and monitor weightof containers with medical fluids such as one or two-liter plastic bagsof collected urine. For example, the overload proof single point loadcell model S300 and the model S215 load cell from Strain MeasurementDevices are particularly suited for scales, weighing bottles or bags inmedical instrumentation applications. Options and various specificationsand mounting configurations of these devices are available. These lowprofile single point sensors are intended for limited space applicationsrequiring accurate measurement of full-scale forces of 2, 4, and 12pounds-force. They can be used with a rigidly mounted platform or tomeasure tensile or compressive forces. A 10,000Ω wheatstone bridgeoffers low power consumption for extended battery life in portableproducts. Other examples of gravimetric scales used to balance medicalfluids using a controller controlling the rates of fluid flow from thepumps in response to the weight information can be found in U.S. Pat.Nos. 5,910,252; 4,132,644; 4,204,957; 4,923,598; and 4,728,433incorporated herein by this reference.

It is understood that there are many known ways in the art ofengineering to measure weight and convert it into computer inputs.Regardless of the implementation, the purpose of the weight measurementis to detect the increasing weight of the collected urine 53 in the bag52 and to adjust the rate of infusion or hydration based on the rate ofurine flow.

Console 82 is also typically equipped with the user interface. Theinterface allows the user to set (dial in) the two main parameters oftherapy: the duration of hydration and the desired net fluid balance atthe end. The net fluid balance can be zero if no fluid gain or loss isdesired. Display indicators on the console show the current status oftherapy: the elapsed time 100 and the net fluid gain or loss 102.

The user interface may also include alarms 104. The alarms notify theuser of therapy events such as an empty fluid bag or a full collectionbag as detected by the weight scale. In one proposed embodiment, theurine is collected by gravity. If urine collection unexpectedly stopsfor any reason, the system will reduce and, if necessary, stop the IVinfusion of fluid and alarm the user. Alternatively, the console caninclude the second (urine) pump (see pump 70, FIG. 2) similar toinfusion pump 22. This configuration has an advantage of not dependingon the bag height for drainage and the capability to automatically flushthe catheter 14, FIG. 3 if it is occluded by temporarily reversing thepump flow direction.

FIG. 4 illustrates an algorithm that can be used by the controllersoftware of controller 34″ to execute the desired therapy. The algorithmis executed periodically based on a controller internal timer clock. Itis appreciated that the algorithm can be made more complex to improvethe performance and safety of the device. Controller 34″, FIG. 3 isprogrammed to determine the rate of change of the urine weight, steps110 and 112, FIG. 4 to calculate a desired infusion rate based on therate of change of the urine weight, step 114, and to adjust the infusionrate of the infusion pump 22, FIG. 3 based on the calculated desiredinfusion rate, step 116, FIG. 4.

So far, the subject invention has been described in connection with thebest mode now known to the applicant. The subject invention, however, isnot to be limited to these disclosed embodiments. Rather, the inventioncovers all of various modifications and equivalent arrangements includedwithin the spirit and scope of the appended claims. Particularly, theembodiments used to illustrate the invention use the weight of thecollected urine for balancing. It is understood that it is the volume ofthe urine that is clinically important but the weight of the urine isequivalent for any practical purpose. For the purpose of thisapplication, 100 grams of urine are the same as 100 ml of urine. It isbelieved at the time of the subject invention that measuring weight ismore practical than measuring volume and that the weight is often usedas a clinically acceptable substitute of volume of liquids that consistmostly of water. For practical purposes, the specific gravity (specificgravity of a substance is a comparison of its density to that of water)of urine and hydration fluids is the same as water. Those skilled in theart will realize that it is possible to measure volume directly using ameter which monitors the height of the column of the liquid in a vesselor by integrating the known volume of strokes of the pump over time. Theexact meter used does not change the subject invention in regard to thebalancing of urine output with hydration. Also, flow meter 36′, FIG. 5could be used to measure the urine output of patient P and a signalcorresponding to the flow rate provided to controller 38. Urine flowmeter 36′, FIG. 5 can be one of the devices disclosed in U.S. Pat. Nos.5,891,051; 5,176,148; 4,504,263; and 4,343,316 hereby incorporatedherein by this reference.

Also a medical device manufacturer, SFM Ltd., 14 Oholiav Street,Jerusalem, 94467, Israel manufactures and markets an electronic flowmeter suitable for use with this invention. According to themanufacturer SFM Ltd. the UREXACT 2000 System is an accurate electronicurine-measuring device that combines an innovative disposable collectionunit with a re-usable automatic electronic meter to provide preciseurine monitoring. The UREXACT 2000 is based on the ultrasonic method ofmeasuring fluid flow.

One potential concern with the use of the embodiment shown in FIG. 3 isthat the weight of hydration fluid at any give time may not alwaysprovide a reliable indication of the true amount of hydration fluidinjected into the patient via pump 22′. For example, IV Pole 84 and/orhydration fluid bag 24 could be jostled affecting the strain gaugemeasurement, hydration fluid bag 24 could leak or, when only partiallyemptied, replaced with a full bag, or bag 24 may not be hanging freelyfrom hook 92.

Similarly, the operation of pump 22′ may not always provide a reliableindication of how much hydration fluid is actually injected into thepatient due to inaccuracies in the pump electronics and the like.

In the subject invention, controller 38 (a microprocessor ormicrocontroller) in console 82, as shown in FIG. 6, controls hydrationpump 22 to infuse the patient with hydration fluid based on thepatient's urine output and keeps track of the hydration fluid injectedin two ways to provide safety and redundancy. First, as discussed above,the weight of hydration fluid source 24, FIG. 3 is monitored as shown at200 in FIG. 6. In addition, the operation history of infusion pump 22 ismonitored by controller 38. Controller 38 may store values representingboth of these measurements in a memory such as PROM 202 and controller38 is programmed as shown in FIG. 7 to store the hydration fluid amountsadministered via the hydration fluid measurement strain gauge, step 220,FIG. 7, and controller 38 is also programmed to store the hydrationfluid amount administered by monitoring of the hydration pump operationhistory, step 222. If there is a difference between these two storedvalues by a predetermined amount, step 224, an alarm signal can begenerated, step 226 so that the potential problem can be corrected.Controller 38 can also be programmed to output an alarm signal if, forexample, the weight of saline bag indicates 50 cc of saline has beeninjected in the last 10 minutes but the pump operation history indicatesonly 20 cc of saline has been injected in the last 10 minutes. Thiscondition would likely indicate the saline bag is not hanging free onhook 90, FIG. 3. The alarm signal can trigger a nurse to check thecondition of the saline bag.

In another possible scenario, the pump operation history does not equateto an amount of hydration fluid administered commensurate with theweight of the saline bag. In such a scenario, controller 38 can beprogrammed to reset the pump and then adjust the operation of the pumpto inject hydration fluid based on the patient's urine output and theweight of the saline bag.

Typically, the controller is also configured to operate pump 22 atpredetermined maximum and minimum infusion rates irrespective of theweight of the saline bag (determined via a first strain gauge), theweight of the urine bag (determined by a second strain gauge), or thepump operation history. An acceptable maximum infusion rate may be 60liters per minute in any 15 minute time period or 22 liters per hour atany time. An acceptable minimum infusion rate may be 1 milliliter perhour per kilogram of patient weight to keep the patient's vein open atthe site of the infusion IV needle 30, FIG. 3 irrespective of the weightof the urine bag.

It is preferable that in any embodiment the hydration system be portablesince patients are often moved in and out and about the cath lab. Whenthe embodiment of FIG. 3 is employed, for example, there are conditionsand events wherein the weight of urine bag 52 may not be indicative ofthe true amount of urine output by the patient at any given time. FIG.8A shows a signal received by the controller from a strain gauge whichmeasures the weight of urine bag 52, FIG. 3 in a situation where theurine bag has been jostled. The signal portion 250, FIG. 8A isindicative of an abnormal patient urine output measurement.

FIG. 8B shows another abnormal patient urine output measurement signalindicative of a urine bag 52, FIG. 3 which has been emptied at time t₁.FIG. 8C shows another abnormal patient urine output measurement signalindicative of a potential problem since the patient's urine output isnot increasing over time as expected. FIG. 8D shows another abnormalpatient urine output measurement indicative of a potential problem sincethe patient's urine output is increasing, beginning at time t₂, at arate higher than expected.

Similarly, it is possible that the weight of hydration fluid bag 24,FIG. 3 may not always be indicative of the true amount of hydrationfluid administered to the patient in any given time period.

FIG. 9A is representative of the signal received by the controller froma strain gauge which measures the weight of hydration fluid bag 24, FIG.3 in the case where the hydration fluid bag has been jostled.

Another abnormal hydration fluid measurement is shown in FIG. 9B whichindicates that at time t₃ an empty hydration fluid bag has been replacedwith a full hydration fluid bag.

In accordance with the preferred embodiment of the subject invention,controller 38, FIG. 6 is responsive, via the strain gauges or othermeasurement devices, to the urine bag weight and also the weight of thehydration fluid bag to achieve a predetermined hydration balance asdiscussed above, step 260, FIG. 10. Controller 38, FIG. 6 is alsoprogrammed to detect a) abnormal patient urine output measurements likethose of FIGS. 8A-8D, step 222, FIGS. 10 and b) abnormal hydration fluidmeasurements like those of FIGS. 9A-9B, step 264, FIG. 10. Thecontroller is further programmed to take corrective action, steps 266and 268 in response to these abnormal measurements. The correctiveaction typically depends on the specific abnormal indication. In thecase of FIG. 8A, which likely is indicative of a jostled urinecollection bag, the urine output measurement is sharply varying and thecontroller can be programmed to control the infusion pump to hydrate thepatient at a preset minimum infusion rate, for example, 1 milliliter perhour per kilogram of patient body weight. This safe minimum level isoften referred to as KVO for “keep vein open” in clinical practice.After the signal settles down as shown at time t₀ in FIG. 8A, thecontroller is programmed to hydrate the patient at an increased ratethereafter to achieve the predetermined hydration balance. Thecontroller software calculates the amount of urine made by the patientduring the occurrence of the sharply varying urine output signal andincreases the infusion rate by controlling the infusion pump to giveback to the patient the volume lost by the patient, the “owed volume”.The automatic administration of the “owed volume” exemplifies thecorrective action. After the predetermined hydration balance isrestored, the infusion rate is returned to the normal level so that thehydration fluid input level matches the urine output level plus or minusany desired net gain or loss. Urine output fluctuates in time andbalancing is, in reality, dynamic based on small time increments. Theycan be less than 1 second long. At the end of each control interval, anew correction can be introduced by controller 38 to the infusion pumpspeed to achieve the goal of balancing in a smooth reasonable way at anallowed rate of change. It is not practical to administer all the “owed”volume immediately. The controller software gives back fluid in smallsafe increments over time, for example, a safe limit of no more than 250milliliters over 15 minutes or a flow rate of no more than 6 liters perhour. Methods of such dynamic control are implemented in the controllersoftware and the safe limits of infusion imbedded in the software or setby the user via the user interface of console 82, FIG. 3.

In another example, when controller 38, FIG. 6 detects the abnormalsignal of FIG. 8A, the controller can be programmed to ignore errantsignal portion 250 and control infusion pump 22, FIG. 6 to maintaininfusion at the rate prior to errant signal portion 250, FIG. 8A. Afterthe errant signal is no longer detected, infusion continues inaccordance with FIG. 4. Rejection of the errant signal is anotherexample of the corrective action by the system.

FIG. 8B illustrates a signal received by the controller indicative of aurine bag that has been at least partially emptied. Other possibilitiesinclude a urine collection bag which leaks or a drain valve that has notbeen completely closed. In such as situation, the controller softwarecan be configured to control the operation of the infusion device basedon the patient's urine output before and after the urine bag was emptiedto achieve the predetermined hydration balance. That is, the controllersoftware extrapolates the urine bag weight as shown at 251 in FIG. 8B toprovide a proper indication of the patient's urine output.

In FIG. 8C, the urine bag weight is not increasing as expected and thecontroller software recognizes and detects this abnormal patient urineoutput measurement and generates an alarm signal to be displayed onconsole 82, at display area 86, FIG. 3. Similarly, in FIG. 8D the urinebag weight sharply increases at time t₂ and the controller software isconfigured to generate another alarm signal.

In the case of abnormal hydration fluid measurement, FIG. 9A isindicative of a source of hydration fluid which has been jostled and thecontroller software is configured to take corrective action in a form ofan alarm signal, for example.

FIGS. 11-12 illustrate the concept of “catching up” or “giving back” thehydration fluid “owed to the patient” when balancing is for some reasontemporarily disrupted. Ideally, as the patient makes urine continuouslyat level 300 hydration would be balanced continuously. In reality, theprocess is frequently interrupted when the urine bag is full anddrained, bags with hydration fluid are empty and replaced or when thepatient is transported and accurate measurements of weight becomeimpossible. In the cathlab environment patients are frequently movedfrom one location to another. It is an object of this invention toenable balanced hydration of the patient throughout the normal flow ofthe cathlab procedure.

As described above, balancing is implemented via periodic reading ofweight scales. In the proposed example, bag 52, FIG. 3 with collectedurine 53 and the bag 24 with hydration fluid 26 are hanging off thehooks 90 and 92 connected to the weight scales. The bags with fluids aresuspended from the hooks that translate force to scales such as loadcells with strain gages. Strain gage converts force into an electronicsignal that can be read by the controller. Suitable electronic devicesfor accurately measuring weight of a suspended bag with urine areavailable from Strain Measurement Devices Inc., (Meriden, Conn.). In thepreferred embodiment two strain gages model SMD S300 designated by thismanufacturer as Load Cells with Integral Overload Protection and 2 Kgcapacity are used to measure and balance weight (and volume) of fluid.These devices include electronics and mechanical components necessary toaccurately measure and monitor weight of containers with medical fluidssuch as one or two-liter plastic bags of collected urine and hydrationfluid. When the patient and the device are moved weight scales areeffected by motion artifacts (inertia) and electronic signals oftenbecome unreliable.

The patient's hydration rate, FIG. 12 is set to the sum of balancingvolume equal to urine output 300, FIG. 11 and net gain 304 during normaloperation. During the time period t₁, a disruption is detected. Forexample, the urine bag may be drained or the weight scale readings areunreliable because of motion.

In one embodiment, the controller software responds in the followingway.

The disruption is detected and the infusion rate is set to safe minimumlevel 310 often referred to as KVO for “keep vein open” in clinicalpractice. For example, KVO can be set to 1 ml/hour per kg of body weightor just 70 ml/h. When the end of the disruption is detected, thesoftware calculates the amount of urine made by the patient during thedisruption time using weight measurement. The system increases theinfusion rate as shown at 312 to give back the volume lost by thepatient—“owed volume”. After the balance is restored, the infusion rateis returned to normal level such as the balance plus the desired netgain 304.

The process so illustrated by FIG. 10 is greatly simplified to emphasizethe point of restoring balance after disruption. It is understood thaturine output fluctuates in time and balancing is in reality dynamicbased on small time increments that can be less than one second long. Atthe end of each control interval new correction is introduced to theinfusion pump speed to achieve the goal of balancing in a smoothreasonable way at an allowed rate of change. Even if the pump capacityallows it, it is not practical to infuse all the “owed” volumeimmediately. The software controls the infusion device to give backfluid in small safe increments spaced over time. For example safe limitcan be set to no more of 250 ml over 15 minutes or flow rate of no morethan 6 liters per hour. Methods of such dynamic control of volume areknown in the field of control engineering and embedded real timesoftware. Safe limits of therapy can be embedded in the software by themanufacturer or set by the user via user interface.

If the disruption is caused by the user changing an infusion fluid bag,infusion flow during the disruption is set to zero. The user can forcethis condition by using the ON/OFF button on the console. The pumpshould be stopped while user is spiking a new bag, otherwise air will bepumped. If a disruption is caused by user draining the urine bag, theinfusion flow can be set to KVO level. The user can force this conditionby pushing the PAUSE button on the console. Alternatively this conditioncan be automatically detected by the weight scale sensing abruptreduction of urine bag weight. If the urine bag is full (as detected bymaximum weight), the system automatically stops balancing and switchesto the KVO mode. An alarm is issued to remind user to drain the bag sometime before the bag is full. For example, if the bag volume is 2 liters,alarm can be issued when the urine weight corresponds to 1.8 liters ofurine.

During pause mode, the controller software generates a low volumebeeping alarm. After 15 minutes, the software increases the volume tohigh to attract attention of the user. At the same time visualindication such as a “PAUSE” message or a Pause LED is used to informthe user of the reason for device beeping.

Upon exit from Pause mode and into run mode, the software canautomatically adapt to the infusion and urine bag weight changes tocorrectly resume hydration control. There are several ways to detectdisruption caused by motion. In a simpler embodiment system softwaredetects that the system console is unplugged from the AC wall outlet andoperating on batteries. During battery operation balancing is turned offand KVO rate of infusion is set. When AC cord is plugged back in thedisruption is considered to be over and the collected urine is measuredand balanced as quickly as practical and safe. Alternatively the devicecan be equipped with a transport key commend activated by user. In asomewhat more complex embodiment software can analyze and detectfluctuations of weight caused by motion inertia and suspend balancinguntil reliable measurements are re-established.

A User Interface

FIG. 13 illustrates an example of a user interface of the proposedembodiment. In the proposed embodiment, the user interface consists oftwo Liquid Crystal Displays 320 and 322 and 11 function keys or buttons328 a-328 j. The LCDs can be 2×24 LCD with LED backlight and 3.2×5.55 mmcharacters part number NHD-0224B0-FSW-GBW from New Haven DisplayInternational (Hoffman Estates, Ill.).

The function keys have following functions. Scroll Key 328 i is intendedto be used to scroll through the system parameters displayed on 320.Parameters such as total urine made, time of therapy, net balance can bedisplayed at any time by user command.

Menu Key 328 b is intended to be used to view the system setting's menu.When in the menu mode user can change parameters of therapy such asdesired hourly net gain, bolus amount or maximum amount of hydrationallowed. Accept Key 328 a is intended to be used to enter (accept)inputs. Clear Key 328 c is intended to be used to cancel inputs andclear alarms. Up Arrow Key 328 h is intended to be used to incrementsettings and navigate the menus and Down Arrow Key 328 g is intended tobe used to decrement settings and navigate the menus. Advance key 328 dis intended to allow manual operation. While key is pressed systemrotates the pump at a preset speed. This mode is used to manually primethe circuit with fluid or advance air bubbles through the tubing.

For example, while the advance key is pressed, the software may run thepump at 60 ml/min. Advance mode may be stopped by releasing the advancekey or when a timeout of 30 seconds of continuous operation has elapsed.After a time out, advance mode may be allowed after the advance key isreleased for 2 seconds.

Set Bolus Key 328 e is intended to allow setting of the bolus amount andduration. Pause Key 328 f is intended to pause the running system orresume operation if paused. After key 328 f is pressed, the systemswitches to fixed KVO infusion rate, no balancing is performed. This keycan be used to suspend balancing while urine bag is drained. It can alsobe used when patient is moved and signals from weight scales aredisturbed. When the system is paused it emits a beeping sound to alertthe user. The status LCD displays a message indicating the pause stateand the elapsed time in the pause state. Run/Stop Key 328 f is intendedto run the system if stopped and stop the system if running.

Prime Key 328 j is intended to initiate a priming process and SilenceKey 328 e is intended to silence the alarm audio. The prime Keyinitiates priming of the circuit with fluid to purge air. The softwaremay enter prime mode to execute the prime test before entering run mode,if a new patient is selected or if the user has pressed the prime key.The prime mode may be cancelled by pressing the stop key.

In order to perform the prime test, the user connects the infusionoutput (tubing 32 on FIG. 3) to the urine input (tubing 16 on FIG. 3).Fluid path is set to pump from hydration bag 26 into urine bag 53. Thesoftware may operate the pump at a speed of 60 ml/min for a period of atleast 2 minutes. This time is sufficient to fill the IV set with fluidand check the weight scale inputs. (The measured hydration fluid volumeis expected to reduce while the measured urine output volume is expectedto increase by the corresponding amount. Thus the pump and weight scalesare tested). If the difference between the change in expected weightsand actual weights is more than, for example, 20%, the software maygenerate an alarm. After priming, the controller software may display amessage to the user that priming is completed and the system is readyfor use. The prime test may complete execution within 5 minutes. Thecontroller software may perform an air detector (86 on FIG. 3, which isin the fluid path) test and generate an alarm if it fails. The airdetector is tested using the test signal which forces a liquid to airtransition. The software may also test the operation of the pressuresensor during priming and generate an alarm on failure.

An Exemplary Circuit Architecture

In one particular example, the main circuit board for controller unit82, FIG. 3 is shown in FIG. 14. Microprocessor 400 is an AtmelAT91SAM7S256 with an ARM7 core, 64Kbytes internal RAM 402 and 256 Kbytesinternal Flash 404. Infusion pump motor controller 406 is an off theshelf brushless DC motor controller which gets power from powermanagement board 430 and uses internal RS232 interface to communicatewith main microprocessor 400.

The load cell outputs for urine bag 52, FIG. 3 and saline bag 24 (loadcells 408 and 410, FIG. 14) are amplified in differential circuit 412and a signal is applied to differential analog to digital converter 414.Programmable logic device (CPLD) 416 is a Xilinx XC95144XL-10 TQ100.Pressure sensor 418 is a medical grade silicon pressure sensor. Thesensor is supplied with 0.910 mA current from a high impedance currentsource to produce 2.3 V at 20 psi on the output of the instrumentationamplifier. Due to the circuit topology there is a constant offset ofabout 0.910V at the IA output at zero pressure. This offset iseliminated in the software. Air bubble detector 420 with its amplifierboard is an off the shelf unit.

Each load cell 408, 410 can be compensated up to +/−1.49 kg by using DACMAX525 422. This compensation is used to cancel out an offset caused bythe load cell offset and gain errors.

At first power up, DAC MAX525 422 is set to middle scale for all theoutputs. This step assures no effect on the offset in the load cellcircuit. Saline and urine channels are compensated by pairs of DACsarranged in push-pull circuit giving the ability of positive andnegative offset compensation. The preferred compensation can be achievedby iterative method. Using linear equation method may be sufficient tokeep ADC 414 full scale in linear range.

Power Management board 430 contains all the circuit controllingoperations of charging Lithium-Polymer battery 432 and switching betweenAC and battery power. The main power supply is a medical gradehigh-efficiency switching power supply. The Displays 401 and 403 and8-Ohm speaker 432 are controlled by the main microprocessor 400. Piezobuzzer 452 is implemented to signal fault conditions which requireoperator attendance. Microprocessor 400 has a UART serial port connector434 and an RS232 transceiver buffer 436 connects this port to a PC.

Microprocessor 400 interfaces with the external pins via its 32 PIOpins. These pins may have different functions as configured by software.Table 1 shows the functions wired to the PIO pins in the hardware. Theshaded boxes in the table show the selections for each pin as“Peripheral A,” “Peripheral B” or assigned as an “I/O” pin. Note thatthe direction of the I/O pins may be input, output or bi-directionaldepending on pin function.

TABLE 1 Microprocessor PIO Pin Assignments

ADC 44 is used to read the two load cells 408 and 410. Table 2 lists thepurpose of the external ADC device inputs.

TABLE 2 External ADC Input Assignments Channel Number Input Purpose 0Load Cell 0 Saline Bag Weight 1 Load Cell 1 Urine Bag Weight

ADC 414 is accessed from microprocessor 400 via the SPI port 440 usingthe chip select signal “ADC_CS#.” This chip select and the SPI interfaceare connected via the microprocessor's PIO interface (see Table 1).

The ADC ready is connected to the microprocessor physically through CPLD416 but is unchanged by the CPLD and is provided to the microprocessorIRQ1 line as shown in the PIO pin list, Table 1.

Table 3 lists the register settings required for ADC operation.

TABLE 3 External ADC Device Register Settings Configuration FilterFunction Register (Hex) Register (Hex) Standard Channel 1 C6 332-Channel Channel 2 56 33 Operation Operational Channel 1 4000C6 33 TestChannel 2 800056 33

ADC 450 inside microprocessor 400 is used to input data from pressuresensor 418, which is wired to the microprocessor's ADC4 input throughconditioning amplifier 452. This input line is direct to the internalADC and does not go through the PIO interface. Also, to verify theanalog voltage (AVCC) in working is checked by measuring half the valueon the ADC input. An SPI quad 12-bit DAC 422 is used set offsetcompensation on each channel.

Sound is generated by the Main board 401 in two ways. One way isstrictly for an alarm function from CPLD watchdog circuitry 416 andcontrols piezo sound device 452. The second way is more versatile and iscontrolled by microprocessor 400 and uses audio DAC 454 device tospeaker 432. This speaker output maybe used for general purpose soundsas well as a full feature alarm and alert sounds.

The I2S audio data output port from the microprocessor is connected toaudio DAC 454 to control and generate the sound. Additionally, DACvolume is controlled via a Two-Wire Interface (TWI) also from themicroprocessor to the audio DAC. Audio DAC 454 may be a Maxim MAX9850with its output to a Texas Instruments TPA6211A1 mono audio amplifier todrive a speaker.

The audio DAC requires a clock in the range between 8.448 and 40 MHz andthis clock is connected to the DAC from the microprocessor on the PCK2line from the Programmable Clock Output Controller of the PMC module. Asampling frequency of 8 kHz should be used for the audio DAC to minimizethe size of the data required.

Microprocessor settings for Audio DAC 454 are list in Table 4.

TABLE 4 Programming table for headphone amplifier MAX9850. RegisterAddress Function B7 B6 B5 B4 B3 B2 B1 B0 0x2 Volume Mute 0 Slew 1VOL(5:0) 0x00 0x3 General GM(1:0) GPD DBDEL(1:0) Mono 0 0 ZDEN Purpose0x2 GPIO Debounce Delay Zero Output 1 0x01 Crossing 1 0x4 Interrupt 0ISGPIO ICLK ISHPS IVMN 0 0 IICH Enable Allow PLL Headphone MinimumOverload 1 alerts 1 Lock 1 Detect 1 Volume 0 0x5 Enable SHDN* MCLKENCPEN(1:0) HPEN LNOEN LNIEN DACEN Power On 1 DAC En 1 Charge PumpHeadphone Line On 1 Line In 0 DAC En 1 0x3 output 1 0x6 Clock 0 0 0 0IC(1:0) 0 0 Internal Clock Divide 0x0 0x7 Charge SR 0 CP(4:0) Pump SlewRate (1:0) Charge pump divider 0x2 0x09 0x8 LRCLK INT MSB (14:8) MSBInteger/Float 0 RLCLK divider 0x0 0x9 LRCLK LSB (7:0) LSB RLCLK divider0x0 0xA Digital MAS INV BCINV LSF DLY RTJ WS(1:0) Audio Master ChannelFalling LSB first Second Right Word Size Order Edge Rising Justified 0x0(16 bits) Latch Edge 0 0 0 0 1 0

Two LCD displays 320 and 324 are interfaced from microprocessor 400 viathe “Parallel Bus” or PB_pins shown in the PIO table. The two enablesignals PB_EN_LCD1 and PB_EN_LCD2 select the respective LCD. The signalPB_RS_AS is used for the LCD interface as the register select (RS)control.

Power Management board 430 consists of three major functions: (1)Battery Charger and Monitor 460, (2) Multiple Source Power Controller462 and (3) Motor power shutoff 464. Multiple Source Power Controller462 switches between the DC voltage from the power supply (18V nominal)and the battery source. The Two-wire interface connects to battery 432.

CPLD 416 has the watchdog alarm logic and the panel switch inputs. Thisinterface uses the “Parallel Bus” (or PB_) which is shared with the LCDinterface. Other hardware signals pass through the CPLD to provide apath to the microprocessor such as the ready signal from the ADC 414.

FIG. 15 shows the timing to read and write data from microprocessor 440to CPLD 416. Registers in the CPLD are assumed to be 8 bits (or twonybbles), so there are two reads or two writes for each data cycle. Thesignal PB_RS_AS is used for the CPLD interface as the address select.The data bus, PB_D[3:0], has the register address when AS is high andthe read or write data when AS is low. The address cycle is always awrite from the microprocessor to the CPLD. The data cycle direction isdetermined by the PB_RW signal with active high as a read cycle.

The 16 CPLD 416 registers are 8 bits, though not all the registers areused. Table 5 lists the registers in the CPLD and the tables 6-12describe the register bits.

TABLE 5 CPLD Registers List Read Register or Address Mnemonic PurposeWrite (hex) CpldId CPLD Identification code == 0x51 R 0 CpldRev CPLDRevision code R 1 Diagnostic Diagnostic Register RW 2 WatchdogPetWatchdog pet register RW 3 Status Status Register R 4 Control ControlRegister W 5 SwitchesL Panel Switches 7:0 R 6 SwitchesH Panel Switches15:8 R 7 MotorSpeedL Motor Speed bits 7:0 R 8 MotorSpeedH Motor Speedbits 15:8 R 9 A B . . . F Note: MotorSpeed is a 16 bit signed number formotor speed in units of RPM.

TABLE 6 CpldId and CpldRev Register Format 7:0 ID[7:0] or Rev[7:0]

ID is the identification code of the DSP board, CPLD=TBD fixed. Rev isthe revision code for the DSP board CPLD.

TABLE 7 Diagnostic Register 7 6 5 4 3 2 1 0 0 0 0 0 Hdr3 Hdr2 Hdr1 hdr0

Hdr[3:0] is the input from the four head lines on the board. Output(writes) to register are ignored.

TABLE 8 Status Register Bit Mnemonic Description 7 POWER_FAILURE# PowerFailure. Also, goes to the FIQ (PA19) line of uP. When first goes lowthe uP power has 50 ms complete all tasks before losing power. 6LOW_BATTERY LOBAT signal from the LT1479 5 DC_IN_GOOD DC Power from thepower supply is good. When this flag is low the DC power is off andtherefore the uP must be powered from the battery. 4 0 3 MtrPwrFdbkMotor Power Feedback. Indicates motor power state on the PM board. (Usedwith watchdog test.) 2 PumpDoorOpen Pump door is open flag 1 wdOutWatchdog output 0 AirDetectorIn Air Detector Input line (1 = air orair-bubbles; 0 = liquid only)

TABLE 9 Control Register Bit Mnemonic Description 7 Enable_piezo Enablepiezo alarm device to sound when watchdog times out. 6 5 BATTERY_OFFDisconnect the battery under SW control. Used when the power supply off(DCIN off). uP power goes off after setting this control bit. 4DCIN_BAT# Select power from the DC power supply when high, from thebattery when low. This may be done automatically by the hardware if userdisconnects AC power (DC_IN_GOOD = 0). 3 CLED2 CPLD diagnostic LED #2 2CLED1 CPLD diagnostic LED #1 1 0 AirDetectorTest Air Detector testoutput. Runs test when in set high when liquid is present. Softwareshould turn bit off after setting. Signal is active low (test runs whenlow).

TABLE 10 Watchdog Register 3 2 1 0 3 2 1 0 0 1 1 1 0 1 0 1

wdec[3:0] is Write a 0x75 to “pet” the watchdog. No other value isvalid.

TABLE 11 SwitchesL, Panel Switches 7:0 Bit Mnemonic Function 7 SW8 CLEAR6 SW7 PRIME 5 SW6 SCROLL 4 SW5 (Upper Center) 3 SW4 ACCEPT 2 SW3 MENU 1SW2 ADVANCE 0 SW1 BOLUS

TABLE 12 SwitchesH, Panel Switches 15:8 Bit Mnemonic Function 7 SW16 Notused = low 6 SW15 Not used = low 5 SW14 SILENCE 4 SW13 RUN/STOP 3 SW12DOWN ARROW 2 SW11 PAUSE 1 SW10 UP ARROW 0 SW9 (Upper Right)

Exemplary Microprocessor Programming

One example of suitable programming for processor or controller 400 isset forth below.

Air Bubble and Pressure Detection and Hydration Settings

Control subsystem 34″, FIG. 3 may also include electronic air detector86 that prevents infusion of air into the patient. The air detector 86is of ultrasonic type and can detect air in amounts exceedingapproximately 50 micro liters traveling inside the infusion tubing 32.In one example, air detector 86 employs technology based on thedifference of the speed of sound in liquid and in gaseous media. If anair bubble is detected, the pump 22′ can be stopped almostinstantaneously.

The controller software reads the bubble detector output and isprogrammed to generate an alarm signal whenever the pump is running andbubbles are detected for more than 540 ms in an 8 minute window. Thebubble detector will detect a 50 μl bubble and generate a minimum pulseof 11 ms.

On power up, the controller software may query the user to select newpatient or same patient using the menus and keys discussed withreference to FIG. 13. If the same patient is selected, the controllersoftware may restore the system settings and control values to resumeoperation before power was turned off.

If a new patient is selected, the software may clear the control values(such as accumulated infusion accumulated urine, bolus delivered) forthe new patient. System settings are restored to their default values.The system settings that are restored from PROM to CPU memory to theirdefault values are Bolus Amount Setting, Net Gain Settings, MaximumHydration Settings, and Minimum Urine Setting.

Upon detection of low power condition, the software may store the systemsettings and other control parameters, needed to restore operation onthe same patient, in non-volatile memory (PROM such as an EEPROM).

A pressure sensor may also be incorporated to measure pressure in theinfusion line downstream of pump 22′, FIG. 3 and upstream the patientI.V. The software may read the pressure sensor to detect occlusions. Ifthe pressure exceeds 15 psi for 30 seconds, for example, the controllersoftware may report an alarm condition. If the pressure exceeds, forexample, 25 psi at any time, or 10 psi for longer than one minute, thesoftware may report an alarm condition. Meanwhile, the controllersoftware may slow down or stop the pump for a short time to allow theocclusion to be resolved on its own before alarming the user. Thesoftware may detect when the Maximum Hydration Limit (set by the user)is reached. In run mode, the software may generate an alert if thecumulative net gain (hydration) exceeds the maximum hydration limit andstop net gain infusion but continue urine balancing. The software mayallow the user to override this condition by increasing or decreasingthe net gain setting at any time via the user interface.

In run mode, the software may generate an alert if the measured urineover a 30 minute period is less than the minimum urine output setting.The setting can be chosen by user, for example from 0 to 500 ml/hour.The infusion fluid weight is used to enhance accuracy of fluid deliveryover time. Reduction of weight in the bag is continuously monitored inaddition to the pump speed to ensure redundancy, added accuracy, and toinform the user in advance that the fluid bag is almost empty.

The urine weight output displays urine volume and urine output rate andenables automatic replacement of fluid lost in urine. The controllersoftware measures urine weight as described herein and adjusts the pumpspeed to add the amount lost in urine to the Net Hydration Gain settingand Bolus Setting set by the user.

Weight measurements can be collected by software every 100 milliseconds.The following software algorithms are applied to the weight scalemeasurements.

The infusion weight scale reading is filtered with a 10 second movingaverage filter. The infusion weight scale is considered to be stable: ifhalf of the samples are within ±16 g of the previous filtered value, orif the difference between the minimum weight reading and the maximumweight reading in the filter window is less than 16 g.

The infusion weight scale may be declared unstable if it does not meetthe stable criteria (defined above) for 15 seconds. The urine weightscale reading is filtered with a 60 second moving average filter. Theurine weight scale is considered to be stable if half the samples arewithin ±100 g of the previous filtered value, or if the differencebetween the minimum weight reading and the maximum weight reading in thefilter window is less than 100 g.

The urine weight scale may be declared unstable if it does not meet thestable criteria (defined above) for 60 seconds. If the weight scale isnot stable, the system switches to the PAUSE (KVO) and alerts the user.

If a weight scale (hydration or urine) is not stable, the systemswitches to the PAUSE (KVO) and alerts the user. KVO means that no urinevolume is replaced, hydration flow is reduced to value sufficient toprevent vein from closing (KVO-Keep Vein Open) and to maintain baselineor minimum hydration. The user has an option to CLEAR or cancel thecondition and the infusion amount equal to the amount of urineaccumulated during PAUSE will be infused into the patient by softwarealgorithm. The later will only occur if the weights scales are nowreliable and stable. In FIG. 9B, the abnormal hydration fluidmeasurement is indicative of a replacement of the source of hydrationfluid and the corrective action taken by the controller software is thegeneration of an alarm signal.

The following additional functions may be embodied by the software usingdata from the weight scales.

During the run mode, the software compares the amount of volumedelivered as determined by the pump rate against the amount of volumedelivered as determined by the weight change of the hydration fluid bagscale. If this difference over a 15 minute period is greater than 50% or25 ml, then the software generates an alarm. During infusion, if the 2liter urine bag measures, for example, more than 1.8 kg, the softwareshall generate an alert. During infusion, if the software measures thestandard one liter hydration bag weight to be less than 50 g (almostempty) or if the software measures the difference between the initialhydration bag weight and the current bag weight to be greater than 950g, it can generate an alarm.

In run mode, the software can generate an alert and go to pause mode ifthe measured urine drops more than 50 g over a 5 minute period. Thereshould not be sudden drops of urine weight. This may indicate openedvalve or disconnected or opened tube.

In run mode, the software may generate an alert and go to pause mode ifthe measure urine increases more than 500 g over a 5 minute period. Thisis an unlikely “physiologic” event and is identified as hardware failureor user misuse such as inadvertently placing additional tension orweight on the hook.

Urine bag 52, FIG. 9 may also include a label instructing the nurse topush pause on controller console 82, FIG. 3 before emptying the urinebag. The function of the pause button is explained with reference toFIG. 13.

One Prototype System

One prototype system includes console 500, FIG. 16 and infusion andurine collection sets. Motion restraining clamp 502 is for urine bag 504chain 506. The integrated infusion set includes an IV bag spike, aLuer-to-Foley connector for priming, and a urine collection set includesan integrated urine bag. The power requirements are 115/ 220 VAC, 60/50Hz, 25 VA. An auxiliary ground post (potential equalization) for thedevice is on the rear of the case (not shown). An RS 232 port is alsoprovided. When mounted on an I.V. Pole, the system requires an area ofapproximately 20×20 inches. Console 500 is placed on the pole so thatthe urine collection bag 504 is above floor level and not touching thefloor or other equipment. Urine collection bag chain 506 is passedthrough motion restrictor ring 502 to prevent excessive swinging of thebag. Urine collection bag 504 is below the level of patient tofacilitate urine drainage, and urine 504 and hydration fluid 512 bagsare hanging freely on hooks 514 and 516, respectively, and not supportedor impeded. Protection tubes 517 and 519 shown in phantom may beprovided about hooks 514 and 516. The urine 518 and hydration 520 tubingshould not kinked or pinched, and should not pull or strain the weightmeasuring devices.

The system maintains hydration balance by measuring patient urine outputand infusing hydration fluid (prescribed by physician) into the patientI.V. to balance the fluid lost in urine. In addition to urine volumereplacement, the system implements a user-set net fluid gain. Net fluidgain is defined as the amount of fluid in ml/hour infused into I.V. inaddition to the replaced volume of urine. The system also allows rapidinfusion of a Bolus of fluid at the user request. The amount of Boluscan be selected by user and typically the bolus is infused over 30minutes. Bolus is infused in addition to the Net Fluid Gain and thereplaced volume of urine. Console 500 includes a microcontroller devicethat has means for measuring urine and the ability to infuse hydrationfluid into the patient. The infusion set allows the console to pumpfluid from a hydration fluid bag to the patient at a controlled rate.The disposable urine collection set collects the patient's urine toallow it to be measured accurately. Console 500 is also equipped with aninternal battery that can sustain operation in the event of power outageor during short periods of time, for example, when the patient is moved.Console 500 includes roller pump 530, user interface 532, two weighingscales (not shown), air detector 535, post-pump pressure sensor 534, anelectrical connector for AC power, and mechanical interfaces for holdingthe set in place. Console 500 controls the rate at which fluid isinfused and monitors urine volume by weight measurement.

To initiate treatment, the system requires: a) peripheral I.V. access536, b) a urinary Foley catheter 538 and c) an appropriate number of oneliter bags with the physician prescribed hydration fluid. The set isautomatically primed by console 500. During the operation, the user isresponsible for a) draining the urine bag when full, b) replacinghydration fluid bags when empty, and c) responding to alarms and alertsissued by the system. Interface 532 can display four lines of text at atime. The system automatically scrolls through the system parameterdisplay items. Each item is displayed for 5 seconds. The user can scrollto the next system parameter display item by pressing scroll key 600,FIG. 17. Depending on the system condition and operating mode, thefollowing parameters are displayed: the net fluid gain accumulated sincethe start of the therapy in ml, the total fluid infused since the startof the therapy in ml, the total urine collected since the start of thetherapy in ml, the urine rate averaged over the last 15 minutes inml/hour, if bolus delivery is in progress, the system displays amount oftime remaining to complete bolus delivery, the operating mode (Run,Pause or Stopped), and the total therapy time. The software alsodisplays the source of power (DC or battery), the amount of estimatedbattery life in minutes and the state of battery charge in percent.Alert or alarm messages, if such a condition exists, are also displayed.The system allows the user to enter following parameters: desired NetFluid Gain in ml/hour, Bolus Amount in ml, maximum allowed accumulatedNet Fluid Gain in ml, and minimum urine output in ml/hour for alertonly.

The system also includes the following features designed to protect thepatient from potentially hazardous conditions and malfunctions and alarmthe user as needed. An air detector 535 with automatic infusion pump 530shut-off, post-pump downstream pressure sensor 534 to detect occlusions,and pump motor speed monitoring by an optical encoder, weight scalemonitoring of infusion fluid to detect leaks and pre-pump upstreamocclusions, weight scale monitoring of urine volume to detect leaks andurine collection set occlusions, free flow protection device 540(pressure valve), and a pump door open detector with automatic motorshut off, critical components of these safety circuits are testedautomatically prior to each therapy. Some components are monitored forintegrity continuously during therapy.

To initiate treatment, medical grade power cord 510 is connected to thepower plug receptacle on the rear of the device. The device is thenplugged into a grounded electrical outlet. The “POWER ON/OFF” key 602,FIG. 17 on the front panel is then pressed. A short tone indicates thediagnostic self-test is starting. The message “Power on Self Test InProgress” is displayed. The device progresses through the test forapproximately 30 seconds. Confirm that the AC MAINS symbol 604 locatedon the front panel is illuminated. If the self-test terminates with anaudible alarm and an error message on the display, make a note of theerror code displayed. If error cannot be corrected, press the POWERON/OFF key, wait 5 seconds, and then repress the “POWER ON/OFF” key asabove. The System progresses to the Same Disposable Set, New DisposableSet. The following message is displayed “Press ACCEPT 606 for SamePatient or CLEAR 608 for New”. Pressing the ACCEPT KEY restores all theparameters used for therapy before power was turned off includingTherapy settings including Bolus administration and Net Gain target, andTherapy parameters such as elapsed time, urine made and fluid infused.Pressing CLEAR KEY 608 indicates that the new infusion set is used onthe same patient or that a new patient therapy is started. All settingsand parameters are restored to zero or system defaults. Before therapyis started the System shall be PRIMED. Priming procedure requiresloading and setting of disposables. Proceed as follows to load theINFUSION SET tubing onto the console. Visually examine the package todetermine that the package has not been opened or damaged duringshipping. Open the package. Release the ties holding the set to thepacking card. Carefully remove the INFUSION SET from the packaging. Usethe I.V. pole to hang the set while preparing to load. Preservesterility. Air detector 535 is connected downstream of the pressuresensor. Start by connecting the infusion line air hydrophobic filter 542to pressure transducer connector 534 on the front of the console. Use agentle but firm turning motion until it stops. Open the pump door 531and load the pump segment tubing over the rollers. Assure that the clipson ends of the raceway are lined up with the tube segment. Close thepump door firmly until a click is heard. Check that the tubing isaligned correctly. When the pump door is open the pump is stopped andcan not move. Spike a hydration bag 512 with the IV Set spike usingstandard technique. Ensure that the drip chamber 550 is at least 50%full by gently squeezing and releasing the chamber. Hang the full 1liter hydration fluid bag on the left chain hook 552 of the console.Ensure free swinging motion of the bag. The system is designed for usewith 1 (one) LITER infusion bags only. Do not use any other bag sizes.Load the infusion set tubing segment immediately to the right of thepressure sensor into air detector 535. Assure that the tubing is firmlyseated at the bottom of the air detector channel. Use stretching orflossing motion to set the tube in the slot. Handle 537 may be providedto seat the tubing in sensor 535. The system is equipped with thesensitive (50 micro liter) ultrasonic air detector. If tubing is notloaded into the detector properly, the System will not operate. Hang theempty urine collection bag 504 on the right chain hook 554 of theconsole. Ensure free swinging motion of the bag. Ensure that the chain506 of the urine bag is passed through retainer clamp 502. The retainerclamp will prevent excessive swinging of the urine bag. Ensure that thebag is hanging unobstructed and unsupported to assure proper weightmeasurements. Check to see that the drain valve 560 at the bottom of theurine collection bag 504 is fully closed. If not, you should close thevalve. Connect a luer connector (normally used for I.V.) on patient endof the infusion set to the foley catheter adapter on the patient end ofthe urine collection set tubing. Use the Foley-to-luer adaptor to makethe connection. This adapter is intended for priming only and isdiscarded before patient use. Use the I.V. pole to support the length oftubing. Ensure that tension is not exerted on the bags and the bagsuspension system. Make sure the clamps on the withdrawal and infusiontubing are open. Press the PRIME button 610 and Press the ACCEPT key 606to start priming the INFUSION SET. The pump will run and stopindependently for approximately 3 minutes. Approximately 150 ml of fluidwill be pumped from the hydration bag 512 into the urine collection bag504. While the pump is running, the user may tap gently on the tubingand/or squeeze the drip chamber to release any bubbles. The user shouldalso inspect the infusion set for any leaks during priming. The user candiscontinue priming by pressing the stop key 612. When the pumps stop,the user may carefully examine the entire infusion set and the filter toassure it fully primed and that no air is present in the blood tubing.If no air is present, the user may proceed to initiating therapy. If anyalarm occurs during priming, refer to the Alarm Section of this manualfor more detailed help in correction of these alarms. Once the problemhas been corrected, the user should re-prime the infusion set prior toinitiating therapy. At the end of automatic priming the System willdisplay message: “Check Weight Bags. Don't Touch Bags.” It is importantnot to interfere with the bag suspension system at this time. Disconnectthe INFUSION SET I.V. connector from Foley Connector of the UrineCollection Set. Remove and discard the Luer-To-Foley adapter. The usermay close the pinch clamp on the infusion line to prevent fluid leakage.Connect the infusion set connector to the already inserted I.V. accessdevice. Assure that no air enters the system. Turn the connector untilit clicks closed. Close the pinch clamp the urine collection tubingprevent fluid leakage. Connect the urine tubing connector from the urinecollection bag to the Foley catheter. Assure the connection does notleak. Press the run button 612 to start therapy. The system has threeuser settable parameters: Net Gain Setting, Maximum Hydration Setting,and Minimum Urine Output Setting. All of these parameters can be viewedand changed using the MENU Key 614. Parameters are changed by selectingfrom the scrolled list using UP and DOWN Arrow keys 616 and 618. Tochange the parameter to selection the user needs to press the ACCEPT Key606. If the user does not press the accept key shortly after making theselection, the screen is cleared, the new value is rejected and thesystem continues with the current value. New parameters are implementedonly after the ACCEPT key is pressed. This value is the amount ofhydration (in ml/hour) that the patient will receive IN ADDITION to thereplacement of urine volume. The net gain is selectable from 0 to 500ml/hr in increments of 25 ml. This setting can be changed at any timeduring therapy using the MENU key selection 614 and the UP and DOWNArrow keys. The FLUID BOLUS is given to the patient is in addition toNET GAIN amount. Default NET GAIN is set to ZERO when the New PatientTherapy is selected. This value is the maximum total amount of NET GAINhydration (in ml/hour) that the patient will receive IN ADDITION to thereplacement of urine volume. The value for maximum hydration isselectable from 0 to 1,500 ml in increments of 100 ml. This setting canbe changed at any time during therapy using the MENU key selection andUP and DOWN Arrow keys. After this value is reached, only urine volumereplacement will occur (net zero replacement). The user is notified byan alert that this level is reached. This number sets the minimumdesired urine output level. This setting does not affect the Systemperformance. If the urine output is consistently below the set valueuser is notified by an alert sound and a display message “Minimum UrineLevel Not Reached”. The minimum urine output setting shall be selectablefrom 0 to 150 ml/hr in increments of 50 ml/hr using UP and DOWN Arrowkeys. The System is designed to stop automatically and alarm when theHydration fluid bag is almost empty (or with approximately 50 ml offluid remaining in the bag). Hydration fluid bags can be also changed atany time by pushing the STOP button and stopping the pump. If userdesires to replace bag that is not empty, user shall push STOP button toavoid air in the circuit. If the bag reaches the minimum acceptablevolume, the System will be stopped. The message “Saline Bag Empty.Replace Saline Bag” will be displayed and alarm sound. The alarm can besilenced using SILENCE button for 2 min. To continue the operation pressCLEAR button. The bag is replace using standard technique common to allI.V. sets with high flow drip chambers. After the bag is replaced,therapy can be restarted by pushing the RUN button. System willautomatically account for the change of weight. The system willautomatically replace fluid lost by patient in urine while the pump wasstopped. This may result in temporary high infusion rate. If the urinebag is full, the system will automatically switch to PAUSE mode. In thePAUSE mode, the system will issue an alert and stop urine volumereplacement. To maintain patency of the venous access, hydration willcontinue but only at a pump flow of 70 ml/hour. The user can empty thebag when full or at any time if desired by the user. The urinecollection bag may emptied by performing the following steps. The systemis designed to alarm the user when the urine collection bag is almostfull. Urine bag holds 2 liters of urine. The system will displaymessage: “Urine Bag Full, Empty Urine Bag”. Push the PAUSE KEY to switchto Pause Mode. Note the total volume in the urine collection bag. Recordit appropriately.

It is the responsibility of the user to push PAUSE button beforedraining the urine bag. Failure to do so, draining bag during withoutPausing the System Operation may result in incorrect measurement anddisplay of urine volume and alarms. Open the drain valve at the bottomof the URINE COLLECTION BAG COUNTERCLOCKWISE and drain into a container.It is recommended that the user drain the urine into a marked containerand record that value prior to discarding the urine. When in PAUSE mode,the system will not replace fluid lost in urine. It is userresponsibility to push the PAUSE or RUN button to restart automaticurine volume replacement. Therapy will not restart automatically untilPAUSE or RUN button is pushed. Close the urine bag valve. PUSH PAUSE KEYto switch back to RUN mode. Do not leave system in the Pause mode unlessintended. The user may empty the urine collection bag prior to it beingfull. Thus, the total number of times the bag was emptied mayoverestimate the total fluid removed. The BOLUS Button allows the userto infuse additional fluid into I.V. when clinically indicated. Thevolume set for the BOLUS is always delivered over 30 minutes. BOLUS Keycan be only used when the device is running. If the device is PAUSED orSTOPPED, a bolus cannot be initiated. Push BOLUS key. The system willdisplay the BOLUS AMOUNT SELECTION Menu. Select bolus amount from 0-250ml in increments of 50 ml using Navigation Keys. Push ACCEPT Key toconfirm the selection. The bolus amount will be delivered over 30minutes in addition to the user set Net Gain and Machine Set UrineVolume Replacement. During the BOLUS delivery the System will displaythe “Bolus Remaining” volume and bolus “Time Remaining” informationautomatically. Bolus Volume is infused in addition to the user set NETGAIN and the replaced URINE VOLUME. If the BOLUS is interrupted by userPAUSE or the System being STOPPED by the user, BOLUS delivery will becompleted as soon as the system returns to normal operation. The Advanceand Pause Keys help user perform maneuvers frequently encountered inI.V. Hydration therapy. The pause mode is similar to the KVO (Keep VeinOpen) mode frequently used in I.V. therapy. It is intended to disableurine volume monitoring and replacement when the urine bag is drained orwhen the patient is moved or urine drainage is re-arranged. Press andHOLD the ADVANCE KEY to displace fluid and air though the INFUSION SET.Releasing the ADVANCE KEY will stop the pump in 2 seconds. If theADVANCE KEY is held continuously for longer than 30 seconds the pumpwill automatically stop. Releasing and pressing and holding the keyagain will allow pump to run for additional 30 seconds.

Air detection is disabled during ADVANCE KEY operation. It is the user'sresponsibility to prevent the infusion of air into the patient. Thesoftware stops the urine volume replacement control when the userpresses the pause key and the system is in run mode. The user may drainthe urine bag during this mode. The software shall resume operation whenthe user presses the PAUSE key and the system is in pause mode. Thesystem runs the pump at a rate of 70 ml/hr to keep the vein open andmaintain I.V. hydration. During pause mode, the system generates a lowvolume beeping. After 15 minutes, the System will increase the volume tohigh to bring to user's attention that the patient is not receivingurine volume replacement. Upon exit from Pause mode and into run mode,the System adapts to the infusion and urine bag weight changes tocorrectly resume hydration control. When the FMS System is PAUSED, theUrine volume is not being replaced. Infusion is set to 70 ml/hour, untilthe user terminates the PAUSE. Silencing and Clearing an Alarm may noteliminate the Alarm cause. Carefully investigate and correct all Alarmsand Alerts.

The alarms generated by the FMS System indicate the presence andseverity of the alarm. The lighted LED and type of sound represent thegeneral level of importance of the current operating conditions to theuser. Press the SILENCE key to silence the alarm for 2 minutes whileperforming corrective actions. Respond to the information displayed onthe screen and correct the conditions that caused the ALARM.

Press the CLEAR Key to reset the alarm. If the FMS-1 is still in RUNMode and the alarm condition is still present, the ALARM willre-annunciate. If the FMS-1 is in STOP Mode, the Alarm condition may becleared but may re-annunciate if the condition has not been removed whenthe system is restarted. Some Alarms such as System Malfunction Alarmscan not be cleared or silenced unless Power is turned OFF and ON.Depending on the cause of an Alarm or Alert System may respond in twoways: alarm the user and stop the pump (for example if Air is detectedor hydration fluid bag is empty) and alarm the user and stop urinevolume replacement while maintaining pump flow at 70 ml/hour (as forexample if urine bag is full).

While the system will provide information on the most likely causes ofthe alarm, the user must exercise caution and examine all possibleoptions if the information displayed does not solve the problem.

The user can select the maximum net gain for single patient THERAPY from0 to 1,500 ml. When this maximum net gain is reached, the systemgenerates an alert. Without user intervention further net gain is notadded to the urine volume replacement, patient therapy is “net zero”balance. The user can override this condition by increasing the net gainsetting at any time. Clear the alarm if no further Net Gain is desiredor change the Maximum Net Gain Setting.

The minimum urine not reached alert is designed to inform the user thatover the period of 30 minutes patient's urine output was below userselected minimum level. This Alert does not affect the System operationand intended to provide information to enable the user to make clinicaldecisions. User can choose to Clear the Alarm, Change the setting orSilence this alarm. The air detected alarm significant amount of air isdetected by the ultrasonic air detection. The infusion pump is stoppedimmediately until user corrective action. This alarm can be caused byair entrained from the damaged or disconnected tubing, air entrainedfrom the drip chamber, or a tube dislodged from the air detector slot.Recommended action includes a check of Leaks and Drip Chamber level, Useof the advance Mode to remove/aspirate air bubble, or a restart oftherapy by pressing RUN key after removing the air.

If an Infusion Set Occlusion Alert is generated, the pressure sensor hasdetected a downstream occlusion of the infusion Line. The Infusion pumpis stopped immediately until user corrective action. This alarm can becaused by closed clamp, a kinked tube, or an occluded I.V. RecommendedAction includes a check of the clamps, a check of the tubing, orflushing the I.V. following the accepted clinical technique.

The Urine Bag Full Alert indicates the system has detected that theUrine Bag is full using the weight scale. Hydration continues at NETGAIN RATE or 70 ml/hr, which ever is higher. Urine volume replacement isdisabled during this time. After the urine is drained, therapy will berestarted as before the alert. Recommended Actions include checking theurine bag level, pressing the PAUSE key, draining the urine bag usingaccepted clinical technique, and push PAUSE key again.

The Fluid Bag Empty Alert indicates the system has detected that theHydration Fluid Bag is almost empty. There can be approximately 50 ml offluid left in the bag. System automatically STOPS the hydration pump.Recommended Actions include checking fluid bag level, replacing the bagusing accepted clinical technique, and pushing the RUN key.

If there is a less than 10 minutes battery life remaining and the systemis powered from battery, the System generates an alert with a low volumeand displays message “Battery Low”. If there is a less than 2 minutesbattery life remaining and the system is powered from battery, thesoftware generates an alarm with a high volume and display message“Battery Critically Low, Connect AC now”.

The system monitors urine weight for abrupt increase that can not beexplained by normal urine output. If an abrupt increase of urine weightis detected an Excessive Urine Weight Increase Alert message is issuedto the user. The system is automatically switched to PAUSE mode.Hydration continues at 70 ml/hr. Urine volume replacement is disabledduring this time. User can CLEAR the alert and therapy will be restartedas before the alert. This alarm can be caused by an object pulling onthe urine scale hook, additional weight added to urine bag, or ahardware malfunction. Recommended Actions include ensuring that Urinecollection bag is freely hanging on the right side hook, clearing theAlert, and push PAUSE key after correcting the condition.

The system monitors urine bag for sudden decrease of weight. If suchdecrease occurs during therapy a Urine Bag Leak Alert is issued. Thisalarm can be caused by the user draining urine without pushing the PAUSEKey, and/or a leak from the bag. Recommended Action includes checkingfor leaks and checking the tubing.

The system relies on weight scales to determine urine output and fluidreplacement rate. If the device is excessively bumped the weight scalereadings can become erratic and unreliable. The System automaticallydetects such conditions and issues an Unstable Scales Alert. If theweight scale is not stable, the system enters the PAUSE modeautomatically. Whenever System is in the PAUSE Mode, urine volume is notbeing replaced. The patient receives 70 ml/hour. When in the PAUSE mode,the System will beep at a low rate and volume. After 15 minutes, theSystem will increase the volume to high to bring to user's attentionthat the patient is receiving only the KVO rate of hydration.Recommended Action includes bringing the system to rest and push PAUSEkey to restart balancing. During patient hydration System monitors theweight of the hydration fluid bag and compares it to the pump flow rate.If serious mismatch is detected an Infusion Weight Mismatch Alert isissued and the Pump is stopped. This alarm can be caused by adisconnected tube, a kinked tube or other kind of Pre-Pump occlusion, ora leaky bag or tube. Recommended Action includes checking for leaks,checking for occlusion, and a restart therapy if the condition iscorrected by pushing RUN key.

If the Pump Door is opened while pump is running, the system generateslow volume beep and displays a Pump Door Open Alert message. If the pumpdoor is opened when the system pump is not running, a message indicatingthat pump door is open will be displayed. Whenever the pump door isopened, the pump rollers will not move and pump will not RUN.

A Prime Test Failure alert may occur at the end of priming. The systemchecks a) the performance of the weight scales by comparing them to eachother, b) the pressure Sensor, and c) the air detector. If this testdoes not pass, patient therapy will not be allowed. Following message isdisplayed “Prime Test Failed” followed by the failed component (i.e.weight scale, pressure sensor or air detector). This alarm can be causedby hardware failure, the user interfering with weight scale measurement,incorrect connection of fluid path during priming, bags not on hooks, atube not in air detector, or a disconnected pressure sensor tube.Recommended actions include ensuring that the infusion set is connectedto the Urine Collection bag and fluid is pumped from former to later,ensuring that urine collection bag is freely hanging on the right sidehook and the hydration fluid bag is freely hanging on the left sidehook, ensure the proper connection of pressure and air sensors, andrepeating the procedure using the PRIME key.

System malfunctions result from internal system diagnostic testscontinuously executed by the system when in operation. They typicallyindicate a possibility of a component malfunction. An alarm is issuedand the system is stopped. System malfunctions, in most cases can not becleared. User is advised to turn power off and on once. If the systemmalfunction condition remains, the system should not be used.

Although specific features of the invention are shown in some drawingsand not in others, this is for convenience only as each feature may becombined with any or all of the other features in accordance with theinvention. For example, there are other ways to determine a patient'surine output and other ways to quantify the amount of hydration fluidadministered to the patient. There are also other ways to redundantlycheck the amount of hydration fluid administered the patient. Also, thewords “including”, “comprising”, “having”, and “with” as used herein areto be interpreted broadly and comprehensively and are not limited to anyphysical interconnection. Moreover, any embodiments disclosed in thesubject application are not to be taken as the only possibleembodiments. Other embodiments will occur to those skilled in the artand are within the following claims.

In addition, any amendment presented during the prosecution of thepatent application for this patent is not a disclaimer of any claimelement presented in the application as filed: those skilled in the artcannot reasonably be expected to draft a claim that would literallyencompass all possible equivalents, many equivalents will beunforeseeable at the time of the amendment and are beyond a fairinterpretation of what is to be surrendered (if anything), the rationaleunderlying the amendment may bear no more than a tangential relation tomany equivalents, and/or there are many other reasons the applicant cannot be expected to describe certain insubstantial substitutes for anyclaim element amended.

1. A patient hydration system comprising: an infusion subsystem whichinfuses an infusion fluid into a patient; a urine output measurementsystem which measures urine output by the patient; and a consoleincluding an input for setting a desired fluid balance; and a controllerassociated with the console responsive to the urine output measurementsubsystem and including a balancing function which controls the infusionsubsystem to administer infusion fluid into the patient based on theinput desired fluid balance and the amount of urine output by thepatient, the controller further configured to: determine one or moreabnormal readings output by the infusion subsystem and/or the urineoutput measurement subsystem including readings indicating a lesseramount of urine than a previous reading, a greater amount of infusionfluid than a previous reading, and/or, a sharply varying urine outputreading or infusion fluid infused reading, and in response to a detectedabnormal reading, control the infusion subsystem according to apredetermined function.
 2. The patient hydration system of claim 1 inwhich the controller is further configured to output a signal if adetected abnormal reading remains for a pre-determined duration.
 3. Thesystem of claim 1 in which a predetermined function controls theinfusion subsystem to infuse infusion fluid at a preset minimum infusionrate until the detected abnormal reading is no longer present and/orwhich controls the infusion subsystem to infuse infusion fluid at a rateestablished prior to detection of the abnormal reading.
 4. The system ofclaim 1 in which the controller is further configured to calculate theamount of urine output by the patient during the occurrence of adetected abnormal reading and to control the infusion subsystem toincrease the amount of infusion fluid infused into the patient based onthe calculated amount of urine output by the patient during theoccurrence of the detected abnormal reading.
 5. The system of claim 1 inwhich the controller is programmed to determine and display on theconsole the amount of infusion fluid infused and an amount of urineoutput by the patient.
 6. The system of claim 5 in which the controlleris programmed to determine the amount of fluid infused and the amount ofurine output by weight.
 7. The system of claim 5 in which the controlleris programmed to calculate the amount of infusion fluid infused over atime interval and to calculate the amount of urine output over a timeinterval.
 8. The patient hydration system of claim 7 in which thecontroller is further configured to output a signal if the calculatednet fluid gain or loss exceeds pre-determined limits.
 9. The system ofclaim 1 in which the controller is further configured to display on theconsole a net fluid gain or loss.
 10. The system of claim 1 in which theurine output measurement subsystem includes a urine collection chamberconnected to the patient.
 11. The system of claim 10 in which the urineoutput measurement subsystem further includes a weighing mechanism forweighing the urine collection chamber.
 12. The system of claim 1 inwhich the controller is configured, based on the input set desired fluidbalance, to administer infusion fluid at a rate equal to, less than, orgreater than the rate of urine output by the patient.
 13. The system ofclaim 1 in which the infusion subsystem includes a pump controlled bythe controller.
 14. The patient hydration system of claim 11 in whichthe pump infuses fluid into the patient from a source of infusion fluid.15. The patient hydration system of claim 14 in which the infusionsubsystem further includes a weighing mechanism the source of infusionfluid and the controller is responsive to said weighing mechanism fordetermining the amount of infusion fluid infused into the patient. 16.The patient hydration system of claim 15 in which the controller isfurther configured to monitor the operation of the pump and to calculatethe amount of infusion fluid infused into the patient based on themonitored operation of the pump.
 17. The patient hydration system ofclaim 16 in which the controller is further configured to output asignal if the determined amount of infusion fluid infused into thepatient based on the weight of the source of infusion fluid differs fromthe calculated amount of fluid infused into the patient based on themonitored operation of the pump by a predetermined amount.
 18. Thesystem of claim 1 in which the controller is configured to determine arate of change of urine output, calculate a desired infusion rate basedon the determined rate of change of urine output and the desired fluidbalance, and to adjust the operation of the infusion subsystem based onthe calculated desired infusion rate.
 19. The system of claim 1 furtherincluding a priming adapter configured to connect the infusion subsystemto the urine output measurement subsystem.
 20. The system of claim 19 inwhich the console includes a priming input and the controller isconfigured, in response to the priming input, to control the infusionsubsystem to drive infusion fluid through the priming adapter into theurine output measurement subsystem.
 21. The system of claim 20 in whichthe controller is further configured to test the operation of theinfusion subsystem and the urine output measurement subsystem inresponse to the priming input.
 22. The system of claim 1 in which theinfusion subsystem further includes a pressure sensor configured todetect occlusions in the infusion subsystem.
 23. The system of claim 22in which the controller is responsive to the pressure sensor andconfigured to interrupt the balancing function in response to a detectedpressure greater than a predetermined pressure.
 24. The system of claim23 in which the controller is further configured to resume the balancingfunction if the detected pressure reduces to a pressure below thepredetermined pressure.
 25. The patient hydration system of claim 22 inwhich the controller is further configured to output an alarm signal ifthe detected pressure remains above the predetermined limit for apredetermined amount of time.
 26. The patient hydration system of claim22 in which the controller is further configured to output an alarmsignal if the detected pressure drops below the predetermined pressurefor a predetermined amount of time.
 27. The patient hydration system ofclaim 23 in which the controller is further configured to output analarm signal if the balancing function is interrupted for apredetermined time.
 28. The system of claim 1 in which the consolefurther includes a bolus input for setting a desired bolus amount ofinfusion fluid and the controller is further configured to control theinfusion subsystem to administer the desired bolus amount of infusionfluid in addition to the desired fluid balance.
 29. The system of claim1 in which the console further includes an input for setting a desiredtherapy time and the controller is configured to control the infusionsubsystem to administer infusion fluid infused into the patient tobalance the urine output with the infusion fluid infused based on theinput desired fluid balance and an input desired therapy time.
 30. Thesystem of claim 1 in which: the console further includes a taper downinput; and the controller further includes a taper down function, thetaper down function, in response to a taper down input, automaticallycontrolling the infusion subsystem to automatically administerincreasingly lesser amount of infusion fluid into the patient.